Une fois que vous avez terminé les sauvegardes, vous êtes prêt à continuer. Pour le reste de ce guide, vous devrez exécuter de nombreuses commandes en tant que root ou en utilisant sudo.

Étape 2 - Recueillir des informations sur le système source

Avant de commencer une migration, vous devez configurer votre système cible pour qu'il corresponde à votre système source.

Vous voudrez faire correspondre autant que possible le serveur actuel et celui vers lequel vous prévoyez de migrer. Vous souhaiterez peut-être mettre à niveau votre serveur actuel avant de migrer vers un système cible plus récent et effectuer un autre ensemble de sauvegardes par la suite. L'important est qu'ils correspondent le plus possible lors du démarrage de la migration proprement dite.

La plupart des informations qui vous aideront à décider quel système de serveur créer pour la nouvelle machine peuvent être récupérées avec la unamecommande :

uname -r

Output

5.4.0-26-generic

Il s'agit de la version du noyau que votre système actuel exécute. Pour que les choses se passent bien, c'est une bonne idée d'essayer de faire correspondre cela sur le système cible.

Vous devez également essayer de faire correspondre la distribution et la version de votre serveur source. Si vous ne connaissez pas la version de la distribution que vous avez installée sur la machine source, vous pouvez le savoir en tapant :

cat /etc/issue

Output

Ubuntu 20.04.3 LTS \n \l

Vous devez créer votre nouveau serveur avec ces mêmes paramètres si possible. Dans ce cas, vous créeriez un système Ubuntu 20.04. Vous devez également essayer de faire correspondre le plus possible la version du noyau. Habituellement, il devrait s'agir du noyau le plus récent disponible dans les référentiels de votre distribution Linux.

Étape 3 - Configurer l'accès à la clé SSH entre les serveurs source et cible

Vous aurez besoin que vos serveurs puissent communiquer afin qu'ils puissent transférer des fichiers. Pour ce faire, vous devez échanger des clés SSH entre eux. Vous pouvez apprendre à configurer des clés SSH sur un serveur Linux .

Vous devrez créer une nouvelle clé sur votre serveur cible afin de pouvoir l'ajouter au authorized_keysfichier de votre serveur existant. C'est plus propre que l'inverse, car de cette façon, le nouveau serveur n'aura pas de clé perdue dans son authorized_keysfichier une fois la migration terminée.

Tout d'abord, sur votre machine de destination, vérifiez que votre utilisateur root ne dispose pas déjà d'une clé SSH en tapant :

ls ~/.ssh

Output

authorized_keys

Si vous voyez des fichiers appelés id_rsa.pubet id_rsa, alors vous avez déjà des clés et vous n'aurez qu'à les transférer.

Si vous ne voyez pas ces fichiers, créez une nouvelle paire de clés en utilisantssh-keygen :

ssh-keygen -t rsa

Appuyez sur "Entrée" à travers toutes les invites pour accepter les valeurs par défaut.

Maintenant, vous pouvez transférer la clé vers le serveur source en la canalisant via ssh:

cat ~/.ssh/id_rsa.pub | ssh other_server_ip "cat >> ~/.ssh/authorized_keys"

Vous devriez maintenant pouvoir vous connecter librement en SSH à votre serveur source depuis le système cible sans fournir de mot de passe :

ssh other_server_ip

Cela rendra toutes les étapes de migration ultérieures beaucoup plus fluides.

Étape 4 - Créer une liste d'exigences

Vous allez maintenant effectuer une analyse approfondie de votre système.

Au cours des opérations, vos exigences logicielles peuvent changer. Parfois, les anciens serveurs ont des services et des logiciels qui étaient nécessaires à un moment donné, mais qui ont été remplacés.

En général, les services inutiles peuvent être désactivés et, s'ils sont totalement inutiles, désinstallés, mais en faire le bilan peut prendre du temps. Vous devrez découvrir quels services sont utilisés sur votre serveur source, puis décider si ces services doivent exister sur votre nouveau serveur.

La manière dont vous découvrez les services et les niveaux d'exécution dépend du type de système "init" utilisé par votre serveur. Le système init est responsable du démarrage et de l'arrêt des services, soit à la demande de l'utilisateur, soit automatiquement. À partir de 2014 environ, presque toutes les principales distributions Linux ont adopté un système d'initialisation appelé Systemd, et ce guide reflétera Systemd.

Afin de répertorier les services enregistrés auprès de Systemd, vous pouvez utiliser la systemctlcommande :

systemctl list-units -t service

Output

UNIT LOAD ACTIVE SUB DESCRIPTION >

accounts-daemon.service loaded active running Accounts Service >

apparmor.service loaded active exited Load AppArmor profiles >

apport.service loaded active exited LSB: automatic crash repor>

atd.service loaded active running Deferred execution schedul>

blk-availability.service loaded active exited Availability of block devi>

cloud-config.service loaded active exited Apply the settings specifi>

cloud-final.service loaded active exited Execute cloud user/final s>

cloud-init-local.service loaded active exited Initial cloud-init job (pr>

cloud-init.service loaded active exited Initial cloud-init job (me>

console-setup.service loaded active exited Set console font and keyma>

containerd.service loaded active running containerd container runti>

…

Pour sa gestion des services, Systemd met en place un concept de « cibles ». Alors que les systèmes avec des systèmes d'initialisation traditionnels ne pouvaient être que dans un "niveau d'exécution" à la fois, un serveur qui utilise Systemd peut atteindre plusieurs cibles simultanément. Ceci est plus flexible dans la pratique, mais il peut être plus difficile de déterminer quels services sont actifs.

Vous pouvez voir quelles cibles sont actuellement actives en tapant :

systemctl list-units -t target

Output

UNIT LOAD ACTIVE SUB DESCRIPTION

basic.target loaded active active Basic System

cloud-config.target loaded active active Cloud-config availability

cloud-init.target loaded active active Cloud-init target

cryptsetup.target loaded active active Local Encrypted Volumes

getty.target loaded active active Login Prompts

graphical.target loaded active active Graphical Interface

local-fs-pre.target loaded active active Local File Systems (Pre)

local-fs.target loaded active active Local File Systems

multi-user.target loaded active active Multi-User System

network-online.target loaded active active Network is Online

…

Vous pouvez lister toutes les cibles disponibles en tapant :

systemctl list-unit-files -t target

Output

UNIT FILE STATE VENDOR PRESET

basic.target static enabled

blockdev@.target static enabled

bluetooth.target static enabled

boot-complete.target static enabled

cloud-config.target static enabled

cloud-init.target enabled-runtime enabled

cryptsetup-pre.target static disabled

cryptsetup.target static enabled

ctrl-alt-del.target disabled enabled

…

De là, vous pouvez découvrir quels services sont associés à chaque cible. Les cibles peuvent avoir des services ou d'autres cibles comme dépendances, vous pouvez donc voir quelles politiques chaque cible implémente en tapant :

systemctl list-dependencies target_name.target

multi-user.targetest une cible couramment utilisée sur les serveurs Systemd qui est atteinte au moment du processus de démarrage où les utilisateurs peuvent se connecter. Par exemple, vous pouvez taper quelque chose comme ceci :

systemctl list-dependencies multi-user.target

● ├─console-setup.service

● ├─containerd.service

● ├─grub-common.service

● ├─grub-initrd-fallback.service

…

Cela répertoriera l'arborescence des dépendances de cette cible, vous donnant une liste des services et autres cibles qui sont démarrés lorsque cette cible est atteinte.

Vérification des services par d'autres méthodes

Bien que la plupart des services configurés par votre gestionnaire de packages soient enregistrés auprès du système init, certains autres logiciels, tels que les déploiements Docker, peuvent ne pas l'être.

Vous pouvez essayer de trouver ces autres services et processus en examinant les ports réseau et les sockets Unix utilisés par ces services. Dans la plupart des cas, les services communiquent entre eux ou avec des entités extérieures d'une manière ou d'une autre. Il n'y a qu'un certain nombre d'interfaces serveur sur lesquelles les services peuvent communiquer, et vérifier ces interfaces est un bon moyen de repérer d'autres services.

Un outil que vous pouvez utiliser pour découvrir les ports réseau et les sockets Unix en cours d'utilisation est netstat. Vous pouvez exécuter netstatavec les -nlpdrapeaux afin d'avoir une vue d'ensemble :

netstat -nlp

•.-nspécifie que les adresses IP numériques doivent être affichées dans la sortie, plutôt que les noms d'hôte ou les noms d'utilisateur. Lors de la vérification d'un serveur local, cela est généralement plus informatif.
•.-lspécifie qui netstatne doit afficher que les sockets en écoute active.
•.-paffiche l'ID de processus ( PID) et le nom de chaque processus utilisant le port ou le socket.

Output

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 104207/vault

tcp 0 0 0.0.0.0:1935 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:1936 0.0.0.0:* LISTEN 197885/stunnel4

tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 162540/systemd-reso

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 129518/sshd: /usr/s

tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 99465/node /root/he

tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:56733 0.0.0.0:* LISTEN 170269/docker-proxy

tcp6 0 0 :::80 :::* LISTEN 3691671/nginx: mast

tcp6 0 0 :::22 :::* LISTEN 129518/sshd: /usr/s

tcp6 0 0 :::443 :::* LISTEN 3691671/nginx: mast

tcp6 0 0 :::56733 :::* LISTEN 170275/docker-proxy

udp 0 0 127.0.0.53:53 0.0.0.0:* 162540/systemd-reso

raw6 0 0 :::58 :::* 7 162524/systemd-netw

Active UNIX domain sockets (only servers)

Proto RefCnt Flags Type State I-Node PID/Program name Path

unix 2 [ ACC ] STREAM LISTENING 5313074 1/systemd /run/systemd/userdb/io.systemd.DynamicUser

unix 2 [ ACC ] SEQPACKET LISTENING 12985 1/systemd /run/udev/control

unix 2 [ ACC ] STREAM LISTENING 12967 1/systemd /run/lvm/lvmpolld.socket

unix 2 [ ACC ] STREAM LISTENING 12980 1/systemd /run/systemd/journal/stdout

unix 2 [ ACC ] STREAM LISTENING 16037236 95187/systemd /run/user/0/systemd/private

…

netstatLa sortie contient deux blocs distincts - un pour les ports réseau et un pour les sockets. Si vous voyez ici des services sur lesquels vous n'avez pas d'informations via le système d'initialisation, vous devrez déterminer pourquoi et si vous avez également l'intention de migrer ces services.

Vous pouvez obtenir des informations similaires sur les ports rendus disponibles par les services à l'aide de la lsofcommande :

lsof

Output

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

node\x20/ 99465 root 20u IPv4 16046039 0t0 TCP 127.0.0.1:3000 (LISTEN)

vault 104207 vault 8u IPv4 1134285 0t0 TCP *:8200 (LISTEN)

sshd 129518 root 3u IPv4 1397496 0t0 TCP *:22 (LISTEN)

sshd 129518 root 4u IPv6 1397507 0t0 TCP *:22 (LISTEN)

systemd-r 162540 systemd-resolve 12u IPv4 5313507 0t0 UDP 127.0.0.53:53

systemd-r 162540 systemd-resolve 13u IPv4 5313508 0t0 TCP 127.0.0.53:53 (LISTEN)

docker-pr 170269 root 4u IPv4 1700561 0t0 TCP *:56733 (LISTEN)

docker-pr 170275 root 4u IPv6 1700573 0t0 TCP *:56733 (LISTEN)

stunnel4 197885 stunnel4 9u IPv4 1917328 0t0 TCP *:1936 (LISTEN)

sshd 3469804 root 4u IPv4 22246413 0t0 TCP 159.203.102.125:22->154.5.29.188:36756 (ESTABLISHED)

nginx 3691671 root 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)

nginx 3691671 root 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)

nginx 3691671 root 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)

nginx 3691671 root 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)

nginx 3691671 root 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)

nginx 3691671 root 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)

nginx 3691671 root 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)

nginx 3691674 www-data 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)

nginx 3691674 www-data 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)

nginx 3691674 www-data 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)

nginx 3691674 www-data 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)

nginx 3691674 www-data 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)

nginx 3691674 www-data 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)

nginx 3691674 www-data 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)

Les deux netstatet lsofsont des outils de gestion de processus Linux de base qui sont utiles dans une variété d'autres contextes.

Étape 5 - Rassemblement des versions de packages

À ce stade, vous devriez avoir une bonne idée des services en cours d'exécution sur votre machine source que vous devez implémenter sur votre serveur cible.

Vous devriez avoir une liste des services que vous savez que vous devrez mettre en œuvre. Pour que la transition se déroule en douceur, il est important d'essayer de faire correspondre les versions dans la mesure du possible.

Vous ne devez pas nécessairement essayer de passer en revue chaque package installé sur le système source et tenter de le répliquer sur le nouveau système, mais vous devez vérifier les composants logiciels qui sont importants pour vos besoins et essayer de trouver leur numéro de version.

Vous pouvez essayer d'obtenir les numéros de version du logiciel lui-même, parfois en passant -vou --versiondes drapeaux à chaque commande, mais cela est plus simple à faire via votre gestionnaire de packages. Si vous êtes sur un système basé sur Ubuntu/Debian, vous pouvez voir quelle version d'un paquet est installée à l'aide de la dpkgcommande :

dpkg -l | grep package_name

Si vous êtes plutôt sur un système basé sur Rocky Linux, RHEL ou Fedora, vous pouvez utiliser rpmdans le même but :

rpm -qa | grep package_name

Cela vous donnera une bonne idée de la version du package que vous souhaitez faire correspondre. Assurez-vous de conserver les numéros de version de tout logiciel pertinent.

Conclusion

Vous devriez maintenant avoir une bonne idée des processus et des services de votre serveur source qui doivent être transférés vers votre nouvelle machine. Vous devez également avoir terminé les étapes préliminaires pour permettre à vos deux serveurs de communiquer entre eux.

Les bases de votre migration sont maintenant terminées. Dans le prochain article de cette série , vous commencerez le processus de migration proprement dit.

Comment migrer des serveurs Linux Partie 2 - Transférer les données de base

Introduction

Dans le dernier article, vous avez préparé votre serveur pour la migration des données . À ce stade, votre système cible et votre système source doivent pouvoir communiquer - le système cible doit avoir un accès SSH au système source. Vous devez également disposer d'une liste des logiciels et des services que vous devez transférer, y compris les numéros de version. Dans ce guide, vous continuerez là où vous vous étiez arrêté et commencerez la migration proprement dite vers votre nouveau serveur.

Remarque : L'idée générale ici est de transférer toutes les informations pertinentes tout en laissant le système cible aussi propre que possible. Certaines stratégies de migration peuvent cloner une partition racine ou lancer une opération de copie à la racine de la machine source tout en excluant manuellement quelques fichiers dont vous savez qu'ils provoqueront des conflits. Cependant, la migration de grandes quantités de données système vers un système d'exploitation actif peut entraîner des résultats imprévisibles ou encombrer inutilement votre nouveau système avec des fichiers qui ne correspondent plus à vos besoins opérationnels. Ce didacticiel migrera plutôt de manière sélective - par inclusion plutôt que par exclusion - pour créer un meilleur résultat final.

Étape 1 - Création d'un script de migration

Ce didacticiel et le suivant seront axés sur la création et l'ajout d'un bashscript shell de migration au fur et à mesure. Vous utiliserez un certain nombre d'outils Linux de bas niveau, et plutôt que d'essayer de les exécuter tous de manière interactive, votre objectif devrait être de vous retrouver avec un ensemble reproductible d'étapes qui peuvent capturer les parties pertinentes de la configuration de votre serveur.

Au fur et à mesure que vous écrivez ce script, vous devriez pouvoir l'exécuter de manière itérative au fur et à mesure. La plupart des outils utilisés dans ce didacticiel, tels que rsync, ne transfèrent les données que si elles ont été modifiées depuis la dernière exécution, afin que vous puissiez répéter les commandes en toute sécurité sans avoir à vous soucier de les rendre redondantes. Étant donné que vous avez configuré SSH pour permettre la connexion à la machine d'origine (source) à partir du nouveau serveur (cible), vous devez travailler à partir du serveur cible tout au long de ce didacticiel.

Vous pouvez créer ce script dans votre répertoire personnel, à l'aide de nanoou de votre éditeur de texte préféré :

nano ~/sync.sh

Sur la première ligne du fichier, ajoutez un en-tête de script, également appelé shebang. Cela indique au script avec quel interpréteur s'exécuter par défaut. #!/bin/bashsignifie que le script utilisera par défaut le bashshell, qui est le shell le plus puissant et le plus largement pris en charge disponible sur la plupart des systèmes.

~/sync.sh

#!/bin/bash

Enregistrez et fermez le fichier pour l'instant. Si vous utilisez nano, appuyez sur Ctrl+X, puis lorsque vous y êtes invité, Ypuis sur Enter.

De retour sur la ligne de commande, rendez le script exécutable en utilisant chmod:

chmod 700 ~/sync.sh

Pour un aperçu détaillé du chmodfonctionnement des autorisations Linux, vous pouvez vous reporter à An Introduction to Linux Permissions .

Après avoir rendu le script exécutable et ajouté le shebang, vous pouvez le lancer en l'appelant directement :

~/sync.sh

Il ne produira pas encore de sortie, car le script est vide. Vous devez tester le script régulièrement tout au long de ce didacticiel si nécessaire. Comme dans le didacticiel précédent de cette série, vous devrez peut-être l'exécuter avec sudodes autorisations, en fonction des étapes que vous ajoutez au script.

Étape 2 - Installation des programmes et services nécessaires

La première étape que vous ajouterez à votre script de migration consistera à restaurer les packages que vous avez marqués pour la migration dans le didacticiel précédent.

Ajouter des référentiels supplémentaires

Avant de faire cela, vous voudrez vous reconnecter à votre serveur d'origine (source) dans un terminal séparé, pour vérifier si vous avez installé des logiciels à partir de référentiels tiers. Si tel est le cas, vous ne pourrez pas réinstaller ces packages dans votre nouvel environnement sans d'abord configurer ces sources de packages supplémentaires.

Dans les environnements Ubuntu et Debian, vous pouvez voir si des référentiels alternatifs sont présents sur votre système source en enquêtant sur quelques emplacements :

cat /etc/apt/sources.list

Output

…

## Uncomment the following two lines to add software from Canonical's

## 'partner' repository.

## This software is not part of Ubuntu, but is offered by Canonical and the

## respective vendors as a service to Ubuntu users.

# deb http://archive.canonical.com/ubuntu impish partner

# deb-src http://archive.canonical.com/ubuntu impish partner

deb http://security.ubuntu.com/ubuntu impish-security main restricted

# deb-src http://security.ubuntu.com/ubuntu impish-security main restricted

deb http://security.ubuntu.com/ubuntu impish-security universe

# deb-src http://security.ubuntu.com/ubuntu impish-security universe

deb http://security.ubuntu.com/ubuntu impish-security multiverse

# deb-src http://security.ubuntu.com/ubuntu impish-security multiverse

Il s'agit de la liste principale des sources de packages — comme il s'agit d'un fichier unique, vous pouvez l'utiliser catpour afficher son contenu. Si la dernière ligne du fichier contient une ubuntu.comadresse, vous n'avez probablement pas ajouté de référentiels tiers à ce fichier. Des référentiels supplémentaires peuvent également être répertoriés dans le sources.list.drépertoire :

ls /etc/apt/sources.list.d

Output

droplet-agent.list elastic-7.x.list nodesource.list

Si ce répertoire n'est pas vide, vous pouvez catles fichiers individuels pour vérifier chacun des référentiels :

cat /etc/apt/sources.list.d/elastic-7.x.list

Output

deb https://artifacts.elastic.co/packages/7.x/apt stable main

Cela vous indiquera l'URL du référentiel que vous devrez rajouter à votre machine cible. Dans la plupart des cas, vous pouvez le faire avec la add-apt-repositorycommande :

sudo add-apt-repository repo_url

Sur RHEL, Rocky ou Fedora Linux, vous pouvez à la place utiliser dnfpour lister les référentiels configurés pour le serveur :

dnf repolist enabled

Vous pouvez ensuite ajouter des référentiels supplémentaires à votre système cible en utilisant dnf config-manager:

sudo dnf config-manager --add-repo repo_url

Si vous apportez des modifications à votre liste source, ajoutez-les sous forme de commentaires en haut de votre script de migration sur votre système cible. De cette façon, si vous devez démarrer à partir d'une nouvelle installation, vous saurez quelles procédures doivent être effectuées avant de tenter une nouvelle migration.

# Add additional repositories to /etc/apt/source.list

# deb http://example.repo.com/linux/deb stable main non-free

Ensuite, enregistrez et fermez le fichier.

Spécification des contraintes de version et installation

Vos sources de packages sont maintenant mises à jour sur votre machine cible pour correspondre à votre machine source.

Sur les machines Ubuntu ou Debian, vous pouvez désormais installer les versions des logiciels dont vous avez besoin sur votre machine cible en tapant :

sudo apt update

sudo apt install package_name=version_number

Si la version du package que vous essayez de faire correspondre date de plus de quelques mois, il se peut qu'elle ait été supprimée des dépôts officiels. Dans ce cas, vous pouvez essayer de rechercher l'ancienne version des .debpackages (par exemple, en parcourant les anciens référentiels en amont ou les PPA tiers) et leurs dépendances et les installer manuellement avec :

sudo dpkg -i package.deb

Cependant, vous devez le faire avec parcimonie pour éviter de créer une situation où vous avez trop de packages avec des incompatibilités de version. Si les anciennes versions du logiciel ne sont pas facilement disponibles, testez d'abord les dernières versions disponibles pour voir si elles répondent toujours à vos besoins, afin d'éviter d'imposer des exigences obsolètes.

Pour RHEL, Rocky ou Fedora Linux, vous pouvez installer des versions spécifiques du logiciel en tapant :

Sudo dnf install package_name-version_number

Si vous avez besoin de traquer les fichiers rpm qui ont été supprimés du référentiel au profit de versions plus récentes, vous pouvez les installer avec dnf :

dnf install package_name.rpm

Encore une fois, gardez une trace des opérations que vous effectuez ici. Vous pouvez les inclure sous forme de commentaires dans le script que vous créez :

# Add additional repositories to /etc/apt/source.list

# deb http://example.repo.com/linux/deb stable main non-free

# Install necessary software and versions

# apt-get update

# apt-get install apache2=2.2.22-1ubuntu1.4 mysql-server=5.5.35-0ubuntu0.12.04.2 libapache2-mod-auth-mysql=4.3.9-13ubuntu3 php5-mysql=5.3.10-1ubuntu3.9 php5=5.3.10-1ubuntu3.9 libapache2-mod-php5=5.3.10-1ubuntu3.9 php5-mcrypt=5.3.5-0ubuntu1

Encore une fois, enregistrez et fermez le fichier.

Étape 3 - Commencez à transférer des données

Le transfert réel des données n'est généralement pas la partie la plus intensive en main-d'œuvre de la migration, mais elle peut être la plus chronophage. Si vous migrez un serveur avec beaucoup de données, c'est probablement une bonne idée de commencer à transférer les données le plus tôt possible.

Rsync est un outil puissant qui offre un large éventail d'options pour répliquer des fichiers et des répertoires dans de nombreux environnements différents, avec une validation de somme de contrôle intégrée et d'autres fonctionnalités. Identifiez les répertoires dont vous souhaitez transférer les données et ajoutez rsyncdes commandes à votre script de migration.

Un exemple rsyncde commande ressemble à ceci :

rsync -azvP --progress source_server:/path/to/directory/to/transfer /path/to/local/directory

-azvPest un ensemble typique d'options Rsync. Comme une ventilation de ce que chacun de ceux-ci fait:

•.aactive le "mode d'archivage" pour cette opération de copie, qui préserve les heures de modification des fichiers, les propriétaires, etc. C'est aussi l'équivalent de fournir chacune des -rlptgoDoptions individuellement (oui, vraiment). Notamment, l' -roption indique à Rsync de parcourir les sous-répertoires pour copier également les fichiers et dossiers imbriqués. Cette option est commune à de nombreuses autres opérations de copie, telles que cpet scp.
•.zcompresse les données pendant le transfert lui-même, si possible. Ceci est utile pour tous les transferts via des connexions lentes, en particulier lors du transfert de données qui se compressent très efficacement, comme les journaux et autres textes.
•.vactive le mode détaillé, afin que vous puissiez lire plus de détails sur votre transfert pendant qu'il est en cours.
•.Pindique à Rsync de conserver des copies partielles de tous les fichiers qui ne sont pas complètement transférés, afin que les transferts puissent être repris ultérieurement.

Vous pouvez en savoir plus sur la façon de créer rsyncdes commandes appropriées en lisant cet article . Dans certains cas, vous devrez peut-être créer les répertoires parents menant à votre destination cible avant d'exécuter rsync .

Avec l'ajout de rsynccommandes, votre script de synchronisation pourrait maintenant ressembler à ceci :

~/sync.sh

#!/bin/bash

#############

# Prep Steps

#############

# Add additional repositories to /etc/apt/source.list

# deb http://example.repo.com/linux/deb stable main non-free

# Install necessary software and versions

# apt-get update

#############

# File Transfer

#############

# Rsync web root

rsync -azvP --progress source_server:/var/www/site1 /var/www/

# Rsync home directories

. . .

N'oubliez pas que ces commandes peuvent être réexécutées et ne transféreront aucune nouvelle donnée à moins que les fichiers source n'aient été modifiés. Vous pouvez donc ajouter des éléments à ce script au fur et à mesure que vous le testez. Soyez prudent et itératif quant aux répertoires que vous incluez.

Migration de bases de données et d'autres données non liées à des fichiers

Notez que vous ne pouvez pas nécessairement copier toutes vos données rsyncsans aucune préparation supplémentaire. De nombreuses applications telles que les bases de données stockent leurs données pertinentes dans plusieurs "fichiers" réels de votre système de fichiers, afin d'optimiser l'accès à l'aide de techniques telles que Database Sharding . Ces fichiers ne sont généralement pas destinés à être consultés ou copiés tels quels ; une base de données expose les données via une interface de requête à la place.

Heureusement, presque toutes les applications qui implémentent leur propre stockage incluront un mécanisme d'exportation et d'importation de données dans des fichiers ordinaires, afin qu'elles puissent être copiées normalement lors de migrations comme celle-ci. Par exemple, si vous utilisez MySQL, vous pouvez consulter Comment importer et exporter des bases de données . Vous pouvez ensuite transférer ces exportations entre les serveurs à l'aide rsyncde ou scp.

Étape 4 - Modification des fichiers de configuration

Bien que certains logiciels recommencent à fonctionner correctement après le transfert des détails et des données de configuration pertinents à partir du serveur d'origine, de nombreuses configurations devront être modifiées.

Cela présente un léger problème pour le script de synchronisation. Si vous exécutez le script pour synchroniser vos données, puis modifiez les valeurs pour refléter les informations correctes pour sa nouvelle destination, ces modifications seront effacées la prochaine fois que vous exécuterez le script. Pour résoudre ce problème, vous pouvez ajouter des étapes supplémentaires au script qui modifieront ces données en place après leur transfert.

Linux inclut un certain nombre d'utilitaires de base qui sont très utiles pour ce type de script de texte. Deux d'entre eux sont sedet awk. En général, sedest plus simple à utiliser si vous apportez des modifications à du texte non structuré à l'aide d'expressions régulières et awkest plus utile pour une analyse plus complexe de texte formaté ou de données tabulaires. Au-delà de ce didacticiel, vous pouvez également en savoir plus sur l'utilisation de sed ou sur l'utilisation de awk .

De cette façon, votre script de synchronisation peut exécuter sedou awkcommandes immédiatement après rsync, afin que vos fichiers soient automatiquement modifiés selon les besoins après avoir été transférés.

sedla syntaxe ressemble à ceci :

sed -i 's/string_to_match/string_to_replace_it_with/g' file_to_edit

L' -iindicateur signifie que le fichier sera modifié sur place plutôt que de créer un fichier de sortie séparé. Le set gne changent pas et sont une sedconvention régulière. Vous pouvez également utiliser des expressions régulières dans lestring_to_match. Essayez d'ajouter une sedcommande à votresync.sh :

~/sync.sh

rsync -avz --progress source_server:/etc/mysql/* /etc/mysql/

# Change socket to '/mysqld/mysqld.sock'

sed -i 's/\/var\/run\/mysqld\/mysqld.sock/\/mysqld\/mysqld.sock/g' /etc/mysql/my.cnf

Cela changera chaque instance de /var/run/mysqld/mysqld.sockin /etc/mysql/my.cnfen /mysqld/mysqld.sock/g. Le \caractère est utilisé pour précéder les /caractères car ils seraient autrement analysés comme la fin de votre sedexpression. C'est ce qu'on appelle l'échappement de caractères spéciaux. Assurez-vous que vos sedcommandes viennent après les rsynccommandes.

Vous pouvez utiliser awkpour le texte formaté de la même manière que vous avez utilisé sedpour le texte non structuré. Par exemple, le /etc/shadowfichier est divisé en onglets délimités par le caractère deux-points (:), qui ressemblent à ceci :

/etc/ombre

vault:!:18941::::::

stunnel4:!:18968:0:99999:7:::

sammy:$6$bscTWIVxvy.KhkO8$NJNhpABhJoybG/vDiRzQ2y9OFEd6XtqgCUG4qkuWfld97VEXH8/jUtc7oMtOC34V47VE7HjdpMMv37Aftdb7C/:18981:0:99999:7:::

Vous pouvez utiliser awkpour supprimer les données de la deuxième "colonne" (c'est-à-dire entre le premier et le deuxième :caractère), comme ceci :

awk 'BEGIN { OFS=FS=":"; } $1=="root" { $2=""; } { print; }' /etc/shadow > shadow.tmp && mv shadow.tmp /etc/shadow

Cette commande indique à awk que les délimiteurs d'entrée et de sortie doivent être analysés comme :. Il spécifie ensuite que si la colonne 1 est égale à "root", alors la colonne 2 doit être définie sur une chaîne vide. Contrairement à sed, awkne prend pas directement en charge la modification des fichiers en place, ce script effectue donc des étapes équivalentes d'écriture dans un fichier temporaire puis d'utilisation mvpour écraser l'entrée d'origine avec le fichier temporaire.

Remarque : bien qu'il sedsoit encore très largement populaire en raison de la flexibilité de l'utilisation d'expressions régulières, awkil est considéré comme quelque peu obscur par les normes modernes et sa syntaxe peut être difficile à apprendre. Si vous travaillez avec des fichiers délimités par des virgules, envisagez d'utiliser un outil plus moderne tel que csvkit .

Vous pouvez toujours ajouter des commentaires à votre script de migration (sur les lignes précédées de #) pour documenter les correctifs en cours ou les modifications apportées à vos fichiers.

Conclusion

Vous devriez maintenant disposer de toutes les informations nécessaires pour migrer vos environnements applicatifs et vos données vers votre nouveau serveur. Vous devez également disposer d'une bonne documentation reproductible pour ce processus si jamais vous deviez redéployer votre pile sur un nouveau système.

Dans le dernier didacticiel de cette série , vous découvrirez comment transférer et tester tous les services système persistants sur votre nouveau serveur.

Comment migrer des serveurs Linux Partie 3 - Dernières étapes

Introduction

Dans le dernier article de cette série, vous avez expliqué comment transférer des packages et d'autres données avec rsync . Dans ce didacticiel, vous terminerez votre migration en migrant des utilisateurs, des groupes, des crontabs et d'autres paramètres.

Étape 1 - Migrer les utilisateurs et les groupes

Les gestionnaires de packages Linux sont très puissants et reproductibles, et en migrant vos packages système dans le didacticiel précédent, vous aurez migré la plupart des paramètres de configuration nécessaires. Cependant, cela omet certains des paramètres que vous avez peut-être modifiés manuellement sur votre ancien serveur, tels que les autorisations d'utilisateur et de groupe. Ceux-ci devront également être migrés ou recréés.

Heureusement, tous les utilisateurs et paramètres de groupe de Linux sont contenus dans quelques fichiers. Ces fichiers incluent :

•./etc/passwd : Ce fichier définit les utilisateurs et leurs attributs. Malgré son nom, ce fichier ne contient pas d'informations sur le mot de passe. Il comprend le nom d'utilisateur, les numéros d'utilisateur et de groupe principal, les répertoires personnels et les shells par défaut.
•./etc/shadow : Ce fichier contient les paramètres de mot de passe réels pour chaque utilisateur. Il doit contenir une ligne pour chacun des utilisateurs définis dans le passwdfichier, ainsi qu'un hachage de leur mot de passe et des informations sur les politiques de mot de passe.
•./etc/group : Ce fichier définit chaque groupe disponible sur votre système. Cela inclut le nom du groupe et le numéro de groupe associé, ainsi que toute appartenance à un groupe.
•./etc/gshadow : Ce fichier contient une ligne pour chaque groupe du système. Il répertorie le nom d'un groupe, un mot de passe qui peut être utilisé par les non-membres du groupe pour accéder au groupe, une liste d'administrateurs et d'autres membres.

Vous ne devez jamais copier ces fichiers directement d'un système live à un autre. Les numéros d'utilisateur et de groupe sont automatiquement incrémentés lorsqu'ils sont créés sur chaque système, et ils créeront des conflits s'ils ne correspondent pas. Au lieu de cela, vous pouvez les migrer de manière sélective à l'aide de awk, comme dans le didacticiel précédent.

Création de fichiers de migration

Vous allez créer un nouveau fichier de migration associé à chacun des fichiers ci-dessus. Cela vous permettra de tous les migrer systématiquement, en commençant par /etc/passwd.

Tout d'abord, vous devrez déterminer si les ID utilisateur réguliers commencent à compter à partir de 500 ou à partir de 1 000 sur votre système source. La plupart des environnements Linux modernes commencent à compter à partir de 1000 pour réserver plus de place aux utilisateurs du système, mais si vous migrez depuis un système très ancien, cela peut compter à partir de 500. Pour vérifier, vous pouvez imprimer les dernières lignes de votre fichier pour voir ce que /etc/passwdvous le numéro de compte utilisateur est :

less /etc/passwd

Output

…

vault:x:997:997::/home/vault:/bin/bash

stunnel4:x:112:119::/var/run/stunnel4:/usr/sbin/nologin

sammy:x:1001:1002::/home/sammy:/bin/sh

Dans ce cas, il s'agirait de 1 000, car vos ID utilisateur habituels, dans la troisième colonne de la sortie, semblent être supérieurs ou égaux à 1 000. Nous n'exporterons pas d'utilisateurs ou de groupes en dessous de cette limite. Vous exclurez également le nobodycompte auquel est automatiquement attribué un ID de 65534.

À l'aide de awk, vous pouvez créer un fichier de synchronisation pour votre /etc/passwdfichier. Les awkcommandes de ce didacticiel seront fournies telles quelles, en raison de leur syntaxe complexe, mais n'oubliez pas que vous pouvez en savoir plus sur l'utilisation d'awk dans un autre didacticiel .

awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync

Ensuite, vous pouvez utiliser la même syntaxe et la même limite d'ID utilisateur pour exporter votre /etc/groupfichier :

awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync

Pour analyser le /etc/shadow, vous pouvez utiliser les données de votre /etc/passwdfichier comme entrée :

awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync

La même approche fonctionne pour /etc/gshadow:

awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync

Après avoir testé ces commandes et vérifié qu'elles créent des fichiers d'exportation à partir de données réelles, vous pouvez les ajouter au sync.shscript que vous avez maintenu depuis le dernier didacticiel. Vous pouvez exécuter chacune de ces commandes à distance, c'est-à-dire dans le cadre du script qui s'exécute sur votre machine cible, en obtenant la sortie de la machine source d'origine, en les faisant précéder de et en enveloppant la commande entre guillemets .ssh awk

`~/sync.sh

ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/passwd > ~/passwd.sync"

ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534)' /etc/group > ~/group.sync"

ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=35534) {print $1}' /etc/passwd | tee - | egrep -f - /etc/shadow > ~/shadow.sync"

ssh source_server "awk -v LIMIT=1000 -F: '($3>=LIMIT) && ($3!=65534) {print $1}' /etc/group | tee - | egrep -f - /etc/gshadow > ~/gshadow.sync"

rsync source_server:~/passwd.sync ~/

rsync source_server:~/group.sync ~/

rsync source_server:~/shadow.sync ~/

rsync source_server:~/gshadow.sync ~/

Après avoir exporté ces données vers votre machine cible, vous pouvez automatiquement ajouter vos utilisateurs et groupes à la machine cible. Contrairement aux autres commandes, cependant, celle-ci créera des doublons si elle est réexécutée dans le même environnement, vous devez donc l'effectuer manuellement plutôt que de l'ajouter à votre script de migration.

Il existe une commande appelée newusersqui peut ajouter plusieurs utilisateurs à partir d'un fichier d'entrée. Cependant, vous devrez d'abord utiliser une autre awkcommande pour supprimer les identifiants numériques de votre fichier de synchronisation :

awk 'BEGIN { OFS=FS=":"; } {$3=""; $4=""; } { print; }' ~/passwd.sync > ~/passwd.sync.mod

Ensuite, vous pouvez transmettre ce fichier ànewusers :

newusers ~/passwd.sync.mod

Cela ajoutera tous les utilisateurs du fichier au /etc/passwdfichier local. Il créera également automatiquement les groupes d'utilisateurs associés. Vous devrez ajouter manuellement des groupes supplémentaires qui ne sont pas associés à un utilisateur dans le /etc/groupfichier. Utilisez vos fichiers de synchronisation comme point de référence pour modifier les fichiers cibles correspondants.

Pour le /etc/shadowfichier, vous pouvez copier la deuxième colonne de votre shadow.syncfichier dans la deuxième colonne du compte associé dans le nouveau système. Cela transférera les mots de passe de vos comptes vers le nouveau système. Vous pouvez également créer un script pour ces modifications, en fonction du nombre de comptes que vous devez transférer.

Étape 2 - Transférer les travaux vers le nouveau système

Maintenant que vos utilisateurs, packages et autres données sont transférés depuis l'ancien système, il reste une étape : transférer chacun des travaux et courriers système de vos utilisateurs.

Le /var/spoolrépertoire sous Linux "contient officiellement des données qui attendent une sorte de traitement ultérieur". En pratique, cela inclut généralement toutes les tâches cron que vous avez configurées, ainsi que tout courrier géré par le système lui-même. Bien que vous ne soyez peut-être pas en train d'exécuter un serveur de messagerie localement , le concept interne de "courrier" de Linux inclut également les journaux et les notifications de certains logiciels, il est donc important de s'assurer qu'ils sont également capturés.

Vous pouvez commencer ce processus en écrivant une autre commande rsync pour le répertoire spool. Le spoolrépertoire contient normalement cron, mailet quelques autres journaux :

ls /var/spool

Output

anacron cron mail plymouth rsyslog

Pour transférer le répertoire mail vers notre serveur cible, vous pouvez ajouter une autre rsynccommande à votre script de migration :

~/sync.sh

rsync -azvP --progress source_server:/var/spool/mail/* /var/spool/mail/

Un autre répertoire dans le /var/spoolrépertoire auquel vous devez prêter attention est le cronrépertoire. Ce répertoire contient des tâches cron, qui sont utilisées pour planifier des tâches. Le crontabssous-répertoire contient la configuration de chaque utilisateur individuel cron.

Transférez votre crontabsutilisationrsync :

~/sync.sh

rsync -azvP --progress source_server:/var/spool/cron/crontabs/* /var/spool/cron/crontabs/*

Cela gérera cronles configurations des utilisateurs individuels. Cependant, il ne capture aucun cronparamètre à l'échelle du système. Dans le /etcrépertoire, il y a un crontab à l'échelle du système et un certain nombre d'autres répertoires qui contiennent crondes paramètres.

ls /etc/cron*

Output

cron.d

cron.daily

cron.hourly

cron.monthly

crontab

cron.weekly

Le crontabfichier contient crondes détails à l'échelle du système. Les autres éléments sont des répertoires contenant d'autres informations cron. Examinez-les et décidez s'ils contiennent des informations dont vous avez besoin.

Encore une fois, utilisez rsyncpour transférer les informations cron pertinentes vers le nouveau système :

rsync -azvP --progress source_server:/etc/crontab /etc/crontab

Pendant que vous étudiez les cronconfigurations dans /etc, assurez-vous de n'avoir oublié aucun autre fichier de configuration. Par exemple, le serveur Web Nginx stocke sa configuration dans /etc/nginx, et vous devez vous assurer que cela a été capturé par votre script de migration.

Une fois que vous avez vos informations cron sur votre nouveau système, vous devez vérifier qu'il fonctionne. La seule façon de le faire correctement est de se connecter en tant qu'utilisateur individuel et d'exécuter manuellement les commandes dans la crontab de chaque utilisateur. Cela garantira qu'il n'y a pas de problèmes d'autorisations ou de chemins de fichiers manquants qui empêcheraient ces commandes d'échouer silencieusement lors de l'exécution automatique.

Étape 3 - Sites et services de test

À ce stade, vous devriez avoir terminé d'ajouter des commandes à votre script de migration et de transférer des données. L'étape suivante consiste à commencer à redémarrer tous vos services pertinents sur le nouveau serveur. Par exemple, vous pouvez redémarrer le nginxserveur Web en exécutant sudo systemctl restart nginx, bien que cela ait été fait automatiquement lorsque vous avez installé le package Nginx sur le nouveau serveur. Pour tous les autres services, pour lesquels vous avez peut-être écrit vos propres fichiers d'unité ou déployés via Docker, vous devez tester leur redémarrage manuel. Vous devez également redémarrer votre serveur au moins une fois pour vous assurer que ces services peuvent reprendre correctement après tout temps d'arrêt. Faites attention à tous les fichiers journaux associés pendant que vous testez pour voir si des problèmes surviennent.

Vous pouvez également effectuer d'autres vérifications ponctuelles. Par exemple, si vous avez un /datarépertoire que vous avez transféré avec rsync, vous pouvez accéder à ce répertoire sur les ordinateurs source et cible et exécuter la ducommande pour vérifier sa taille :

cd /data

du -hs

Output

471M .

S'il y a une disparité entre vos deux systèmes, vous devriez enquêter.

Ensuite, vous pouvez vérifier les processus en cours d'exécution sur chaque machine. Vous pouvez utiliser toppour obtenir un aperçu des processus actifs :

top

Output

top - 21:20:33 up 182 days, 22:04, 1 user, load average: 0.00, 0.01, 0.00

Tasks: 124 total, 3 running, 121 sleeping, 0 stopped, 0 zombie

%Cpu(s): 1.0 us, 1.0 sy, 0.0 ni, 98.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

MiB Mem : 981.3 total, 82.8 free, 517.8 used, 380.7 buff/cache

MiB Swap: 0.0 total, 0.0 free, 0.0 used. 182.0 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

11 root 20 0 0 0 0 I 0.3 0.0 29:45.20 rcu_sched

99465 root 20 0 685508 27396 5372 S 0.3 2.7 161:41.83 node /root/hell

104207 vault 20 0 837416 236528 128012 S 0.3 23.5 134:53.49 vault

175635 root 20 0 11000 3824 3176 R 0.3 0.4 0:00.03 top

1 root 20 0 170636 9116 4200 S 0.0 0.9 8:50.40 systemd

2 root 20 0 0 0 0 S 0.0 0.0 0:01.04 kthreadd

3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp

4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp

. . .

Vous pouvez également répliquer certaines des vérifications que vous avez effectuées initialement sur la machine source pour voir si vous avez correctement reproduit votre environnement sur la nouvelle machine. Vous pouvez à nouveau exécuter netstatavec les -nlpdrapeaux pour avoir un aperçu :

netstat -nlp

Output

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 0.0.0.0:8200 0.0.0.0:* LISTEN 104207/vault

tcp 0 0 0.0.0.0:1935 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:1936 0.0.0.0:* LISTEN 197885/stunnel4

tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 162540/systemd-reso

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 129518/sshd: /usr/s

tcp 0 0 127.0.0.1:3000 0.0.0.0:* LISTEN 99465/node /root/he

tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3691671/nginx: mast

tcp 0 0 0.0.0.0:56733 0.0.0.0:* LISTEN 170269/docker-proxy

tcp6 0 0 :::80 :::* LISTEN 3691671/nginx: mast

tcp6 0 0 :::22 :::* LISTEN 129518/sshd: /usr/s

tcp6 0 0 :::443 :::* LISTEN 3691671/nginx: mast

tcp6 0 0 :::56733 :::* LISTEN 170275/docker-proxy

udp 0 0 127.0.0.53:53 0.0.0.0:* 162540/systemd-reso

raw6 0 0 :::58 :::* 7 162524/systemd-netw

Active UNIX domain sockets (only servers)

Proto RefCnt Flags Type State I-Node PID/Program name Path

unix 2 [ ACC ] STREAM LISTENING 5313074 1/systemd /run/systemd/userdb/io.systemd.DynamicUser

unix 2 [ ACC ] SEQPACKET LISTENING 12985 1/systemd /run/udev/control

unix 2 [ ACC ] STREAM LISTENING 12967 1/systemd /run/lvm/lvmpolld.socket

unix 2 [ ACC ] STREAM LISTENING 12980 1/systemd /run/systemd/journal/stdout

unix 2 [ ACC ] STREAM LISTENING 16037236 95187/systemd /run/user/0/systemd/private

…

Vous pouvez également relancer lsof:

lsof

Output

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

node\x20/ 99465 root 20u IPv4 16046039 0t0 TCP 127.0.0.1:3000 (LISTEN)

vault 104207 vault 8u IPv4 1134285 0t0 TCP *:8200 (LISTEN)

sshd 129518 root 3u IPv4 1397496 0t0 TCP *:22 (LISTEN)

sshd 129518 root 4u IPv6 1397507 0t0 TCP *:22 (LISTEN)

systemd-r 162540 systemd-resolve 12u IPv4 5313507 0t0 UDP 127.0.0.53:53

systemd-r 162540 systemd-resolve 13u IPv4 5313508 0t0 TCP 127.0.0.53:53 (LISTEN)

docker-pr 170269 root 4u IPv4 1700561 0t0 TCP *:56733 (LISTEN)

docker-pr 170275 root 4u IPv6 1700573 0t0 TCP *:56733 (LISTEN)

stunnel4 197885 stunnel4 9u IPv4 1917328 0t0 TCP *:1936 (LISTEN)

sshd 3469804 root 4u IPv4 22246413 0t0 TCP 159.203.102.125:22->154.5.29.188:36756 (ESTABLISHED)

nginx 3691671 root 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)

nginx 3691671 root 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)

nginx 3691671 root 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)

nginx 3691671 root 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)

nginx 3691671 root 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)

nginx 3691671 root 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)

nginx 3691671 root 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)

nginx 3691674 www-data 7u IPv4 2579911 0t0 TCP *:8080 (LISTEN)

nginx 3691674 www-data 8u IPv4 1921506 0t0 TCP *:80 (LISTEN)

nginx 3691674 www-data 9u IPv6 1921507 0t0 TCP *:80 (LISTEN)

nginx 3691674 www-data 10u IPv6 1921508 0t0 TCP *:443 (LISTEN)

nginx 3691674 www-data 11u IPv4 1921509 0t0 TCP *:443 (LISTEN)

nginx 3691674 www-data 12u IPv4 2579912 0t0 TCP *:8088 (LISTEN)

nginx 3691674 www-data 13u IPv4 2579913 0t0 TCP *:1935 (LISTEN)

Si vous avez transféré un serveur Web ou des applications Web, vous devez également tester vos sites sur le nouveau serveur. Selon votre configuration, vous devrez peut-être migrer votre nom de domaine et réenregistrer les certificats HTTPS avant de pouvoir le faire. Si votre nouveau serveur se trouve derrière un VPN ou une autre couche d'entrée, vous pourrez peut-être le tester derrière une URL différente avant d'effectuer une transition de production complète.

Vous souhaiterez également migrer vos règles de pare-feu , qui sont généralement contenues dans /etc/sysconfig/iptableset /etc/sysconfig/ip6tables.

Avant de charger les règles dans votre nouveau serveur, vous devez les examiner pour tout ce qui doit être mis à jour, comme les adresses IP ou les plages modifiées.

Étape 4 - Modifier les paramètres DNS

Une fois que vous disposez de toutes les données les plus récentes sur votre serveur cible et que vous avez testé vos points de terminaison Web, vous pouvez modifier les serveurs DNS de votre domaine pour qu'ils pointent vers votre nouveau serveur. Assurez-vous que chaque référence à l'adresse IP de l'ancien serveur est remplacée par les informations du nouveau serveur.

Si vous utilisez les serveurs DNS de DigitalOcean, vous pouvez lire comment configurer vos noms de domaine .

Les modifications DNS prennent généralement de quelques minutes à une heure pour se propager à la plupart des FAI Internet à domicile. Une fois que votre DNS a été mis à jour pour refléter vos modifications, vous devrez peut-être exécuter le script de migration une dernière fois pour vous assurer que toutes les demandes parasites qui allaient encore à votre serveur d'origine sont transférées.

Conclusion

Votre nouveau serveur devrait maintenant être opérationnel, accepter les demandes et gérer toutes les données qui se trouvaient sur votre ancien serveur. Vous devez continuer à surveiller de près le nouveau serveur pour toute anomalie.

Les migrations ne sont pas anodines. La meilleure chance de réussir la migration d'un serveur en direct est de comprendre votre système du mieux possible avant de commencer. Chaque système est différent et à chaque fois, vous devrez contourner de nouveaux problèmes. N'essayez pas de migrer si vous n'avez pas le temps de résoudre les problèmes qui peuvent survenir.

Ensuite, vous souhaiterez peut-être en savoir plus sur la configuration et le déploiement de serveurs avec Ansible .